An unbounded transactional memory (UTM) enables arbitrarily large transactions in time and memory footprint to occur through a combination of hardware acceleration using hardware and software. Running and implementing UTM transactions typically require specially compiled code for implementing concurrency control mechanisms with UTM hardware acceleration interfaces. As a result, UTM transactions may not operate correctly if the execution of the UTM compiled code is intervened by a user-level asynchronous event and subsequent execution of user runtime code that is not compiled for the UTM execution.
One of the main causes of user-level asynchronous events is handling of a hardware exception at a user-level exception (or signal) handler. An exception is an event that occurs during program execution that requires execution of a special code path, called the exception handler, outside the normal execution flow of control. Hardware exception conditions are detected by hardware and reported to an operating system (OS). Examples of hardware exceptions include a divide-by-zero operation or an attempt to access an invalid memory address location. On occurrence of such an exception, control typically passes from user-level code to the OS. When the OS receives control to process such exception events, it typically attempts to dispatch the exception to a proper exception handler associated with the program that raised the exception.
When a hardware exception is detected and raised from the user mode program, the OS typically collects exception information, transfers it to a user stack, and transitions back to the user mode, and dispatches the exception to a user mode exception handler. In many modern operating systems such as WINDOWS, UNIX and LINUX OS's, default user-level runtime code, which is not compiled for UTM execution, is provided to handle a dispatch request for a user mode exception (signal) from the operating system. Therefore, a UTM application and its runtime system face a serious technical challenge for dealing with exception handling and asynchronous invocation of the user-level exception dispatch and handling code during a UTM transaction.
For example, one of the main causes of asynchronous execution of the OS user runtime code is servicing an exception dispatch request from the OS kernel code to support signal programming (e.g., signals in UNIX operating systems) and user-level exception handling (e.g., SEH in WINDOWS operating systems). This user mode service routine for receiving a request from the OS kernel and dispatching an exception to the target exception handler is part of the default user runtime system provided by the operating system. Existing OS kernel code and OS user runtime code are not part of the UTM runtime system and have limited or no knowledge about UTM implementation schemes and various UTM hardware operation modes.
As a result, asynchronous dispatch to the OS user runtime code and subsequent execution of the OS user runtime during a UTM transaction may result in yielding incorrect operations and results. One simple solution is to always cause an abort of a pending transaction upon a hardware exception during UTM execution and allow the UTM runtime system to restart the transaction in a software transactional memory (STM) mode with no UTM hardware acceleration. However, this solution leads to a significant performance slow down for a UTM thread, particularly when the program involves frequent exception handlings such as floating point exception filtering. Thus a UTM thread suffers from expensive abort and restart operations and UTM hardware acceleration cannot be realized for certain transaction code execution.